In large Enterprise Level Database installations, performance is critical. Business conditions place pressure on extracting more performance with minimal expenses. To achieve more performance, installations/changes that are made to the databases are accurately assessed before implementation in the real time Production system. Changes could include, upgrading the database or modifying the database configurations for tuning purposes. After the changes are made, assessment of possible risks is performed in order to be confident that the changes do not cause problems in the production system. For this purposes, organizations have relied on traditional simulators and extensive testing and validation techniques or test scripts which fire the same production workload onto a Test Database.
Traditional approaches have relied on intrusive solutions, such as using Database Transaction Logs to capture production workload. These solutions lay finite load on the database performance which is undesirable in production environments. These approaches are also have an ineffective way of identifying the change responses since they capture only updates to the database and do not capture ‘Select’ queries or read-only queries made to the database. They also do not capture the native complexity involved such as the interaction amongst different client sessions and timing issues.
To effectively analyze the changes, administrators need to have the complete workload with all of the client sessions, users, Queries, timing and Concurrency present in the original workload to be replicated to a Test Database during the replay without the imposing undue load on the production server during the capture.
Currently, the only available solution which satisfies most of these requirements is Oracle DBReplay provided by Oracle. This solution relies on capturing the complete workload directly from the Oracle Production Server process. The Oracle production server will record all transactions onto local disk storage. However, Oracle DBReplay places some load on the production database. Furthermore, Oracle DBReplay is only supported for Oracle databases.
Some of the documents which are available in this area include U.S. Pat. No. 7,096,264 granted to Bonney et al., U.S. Patent Publication No. 2005/0141432 filed by Mihai Sirbu, U.S. Patent Publication No. 2008/0097995 filed by Dias et al., and 2008/0097996 filed by Dias et al., contents of each of which is incorporated herein.
Therefore, there arises a need for a system and a method that does not place any load on the Production Database overcoming the problems existing in the art.